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In our discussion on Friday, there seemed to be some confusion over the complexibility and 
understandability of monitors as opposed to messages. Comparing the two proposals 
(<Redell>MesaProc.memo and <Lauer>SendMessages.memo) in this respect is like 
comparing apples and oranges; they are really aimed at two different levels of system. 
Accordingly, I have sketched very quickly here a stripped-down version of the monitor 
proposal which is the exact dual of the message system I previously outlined. My serious 
concern is that this level of system is not adequate to our needs, even now, and that the 
process working group was quite right to extend their recommendation beyond this basic 
skeleton. If that is the case, then the same must be done to the message proposal. In any 
case, neither proposal is ready for implementation without a thorough technical review. 

Simple monitors 

The following are the salient features of the simple monitor scheme, listed along with their 
duals from the simple message scheme. It is assumed that each would be implemented in 
the same medium (i.e., both or neither in microcode) but that the monitors would be 
embedded into Mesa. 



Monitors 

Monitored modules 
NEW <module name> 
FORK < process name> 

JOIN 

PROCESS declaration plus . 
entry condition variables 

RETURN 



Messages 

Processes 

CreateProcess 

SendMessage 

AwaitReply 

WaitForMessage plus mask 



SendReply 



There are several differences between this list and the monitor proposal, 
following important ones: 



including the 



condition variables have a simpler character, possibly not as flexible or usable (but 
this is open to question). 

monitored objects are not included, yet these are very important to most of the 
components of Pilot, especially the communications facilities, memory 
management, and file support. 
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time-outs and aborts on condition variable waits are not provided; the process 
working group seems to feel strongly about these, though I would scrutinize 
this carefully in a technical review. 

If these facilities are required by our systems and/or applications programmers in order to 
make monitors useful, then by the duality argument, corresponding facilities are needed in 
the message system. My proposal would then have to be augmented to include them; this 
would increase the complexity of the implementation and make the mechanism exactly as 
difficult to comprehend as the monitor scheme. This is not surprising, since the programs 
which would be written in the two schemes would be almost identical to each other, anyway. 



